1. Field of the Invention
The invention relates to the field of integrated circuit modeling, and in particular to a system and method for accurately representing the effects of multi-drive conditions.
2. Related Art
An electronic design automation (EDA) system is a computer software system used for designing integrated circuit (IC) devices. The EDA system typically receives one or more high level behavioral descriptions of an IC device (e.g., in HDL languages like VHDL, Verilog, etc.) and translates (“synthesizes”) this high-level design language description into netlists of various levels of abstraction. A netlist describes the IC design and is composed of nodes (functional elements) and edges, e.g., connections between nodes. At a higher level of abstraction, a generic netlist is typically produced based on technology independent primitives.
The generic netlist can be translated into a lower level technology-specific netlist based on a technology-specific (characterized) cell library that has gate-specific models for each cell (i.e., a functional element, such as an AND gate, an inverter, or a multiplexer). The models define performance parameters for the cells; e.g., parameters related to the operational behavior of the cells, such as power consumption, output slew, delay, and noise. The netlist and cell library are typically stored in computer readable media within the EDA system and are processed and verified using many well-known techniques.
FIG. 1 shows a simplified representation of an exemplary digital ASIC design flow. At a high level, the process starts with the product idea (step E100) and is realized in an EDA software design process (step E110). When the design is finalized, it can be taped-out (event E140). After tape out, the fabrication process (step E150) and packaging and assembly processes (step E160) occur resulting, ultimately, in finished chips (result E170).
The EDA software design process (step E110) is actually composed of a number of steps E112-E130, shown in linear fashion for simplicity. In an actual ASIC design process, the particular design might have to go back through steps until certain tests are passed. Similarly, in any actual design process, these steps may occur in different orders and combinations. This description is therefore provided by way of context and general explanation rather than as a specific, or recommended, design flow for a particular ASIC.
A brief description of the components steps of the EDA software design process (step E110) will now be provided. During system design (step E112), the designers describe the functionality that they want to implement and can perform what-if planning to refine functionality, check costs, etc. Hardware-software architecture partitioning can occur at this stage. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include Model Architect, Saber, System Studio, and DesignWare® products.
During logic design and functional verification (step E114), the VHDL or Verilog code for modules in the system is written and the design is checked for functional accuracy. More specifically, the design is checked to ensure that it produces the correct outputs. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include VCS, VERA, DesignWare®, Magellan, Formality, ESP and LEDA products.
During synthesis and design for test (step E116), the VHDL/Verilog is translated to a netlist. The netlist can be optimized for the target technology. Additionally, the design and implementation of tests to permit checking of the finished chip occurs. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include Design Compiler®, Physical Compiler, Test Compiler, Power Compiler, FPGA Compiler, Tetramax, and DesignWare® products.
During design planning (step E118), an overall floorplan for the chip is constructed and analyzed for timing and top-level routing. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include Jupiter and Floorplan Compiler products.
During netlist verification (step E120), the netlist is checked for compliance with timing constraints and for correspondence with the VHDL/Verilog source code. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include VCS, VERA, Formality and PrimeTime products.
During physical implementation (step E122), placement (positioning of circuit elements) and routing (connection of the same) is performed. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include the Astro product.
During analysis and extraction (step E124), the circuit function is verified at a transistor level, this in turn permits what-if refinement. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include Star RC/XT, Raphael, and Aurora products.
During physical verification (step E126), various checking functions are performed to ensure correctness for: manufacturing, electrical issues, lithographic issues, and circuitry. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include the Hercules product.
During resolution enhancement (step E128), geometric manipulations of the layout are performed to improve manufacturability of the design. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include the iN-Phase, Proteus, and AFGen products.
Finally, during mask data preparation (step E130), the “tape-out” data for production of masks for lithographic use to produce finished chips is performed. Exemplary EDA software products from Synopsys, Inc. that can be used at this step include the CATS® family of products.
As indicated in FIG. 1, timing analyses can be performed at various points along the EDA process, such as during synthesis, design planning, netlist verification, and analysis (as indicated by the bolded chevrons). The accuracy of these timing analyses is critical to the quality of final IC produced using EDA systems. To perform a timing analysis, the IC design (or a portion of the IC) is defined as a network of drivers and receivers. Cells designated as drivers provide stimuli to the network, and the resulting waveforms are received by the cells designated as receivers.
For example, FIG. 2 shows a schematic diagram of a sample driver-receiver network 200 that includes a driver (cell) 210 and a receiver (cell) 230. An input pin 211 of driver 210 receives a driver input signal S_IND and generates a driver output signal S_OUTD at a driver output pin 212. This signal is transmitted across an interconnect element 220 and is received as a receiver input signal S_INR at a receiver input pin 231 of receiver 230 (depicted as an inverter for exemplary purposes). Receiver 230 processes receiver input signal S_INR and generates a receiver output signal S_OUTR at a receiver output pin 232. Note that receiver 230 can also function as a driver for downstream cells, as indicated by load 240 connected to receiver output pin 232.
Conventional driver models represent transistor behavior by indexing the output voltage behavior of the driver by input slew and output capacitance. For example, FIG. 3A shows a conventional driver model 210A for modeling driver cell 210 shown in FIG. 2. Driver model 210A includes a time-dependent voltage source V210A in series with a drive resistor R210A and driver output pin 212A, and an output capacitor C210A coupled between pin 212A and ground. Driver model 210A is sometimes referred to as a “Thevenin model”. Driver model 210A is precharacterized by applying a range of driver input signals S_INA to input pin 211A across a range of capacitance values C1 through CN for output capacitor C210A (via SPICE simulations or actual device measurements). Each input signal S_INA exhibits a particular input slew SI (i.e., the time required for the signal to go from one logic state to the opposite logic state) and a particular input delay time TDI (i.e., the time at which input signal S_INA reaches a threshold level (generally 50% of the signal swing)). The output voltage signals V_OUT(t) generated in response to the various input signals S_INA each exhibit a particular output slew SO and an output delay time TDO. By subtracting the input delay time TDI of an input signal S_INA from the output delay time TDO of an associated output signal S_OUTA, an output delay value DOUT can be determined. The output slew SO and the output delay value DOUT for each of output signals S_OUTA can then be indexed by input slew SI and output capacitance values C1 through CN in a precharacterized library cell entry for driver cell 210.
Thus, conventional precharacterized library cell entries for driver cells generally include output voltage curve characteristics (i.e., output slew and output delay) as precharacterization output signals, with output capacitance, input slew, and signal type acting as indexing parameters. For example, FIG. 3B shows a precharacterized library cell entry 300 generated by driver model 210A in FIG. 3A. Cell entry 300 includes a set of precharacterized driver output signal data stored as output delays DOxx and output slews SOxx indexed by input slews SI1 through SI4 and output capacitances C1 through C4. Thus, for example, output delay DO11 is indexed by input slew SI1 and output capacitance C1. Output slew SO11 is indexed by the same indexing parameter values (i.e., input slew SI1 and output capacitance C1). In some cases, a driver cell may be associated with separate library entries for output delay and output slew (i.e., output delay and output slew values that are indexed by separate sets of input slew and output capacitance values).
Note that because the behavior of a cell can vary according to the type of signal being applied to that cell, the output delay and output slew values in cell entry 300 can also be indexed according to input signal type (i.e., rising signals, falling signals, “best case” (fastest) transitions, and “worst case” (slowest) transitions). Thus, for example, output delay value DO14 (circled) can include a set of output delay values DO14-R, DO14-F, DO14-B, and DO14-W, which correspond to rising, falling, “best case”, and “worst case” signals, respectively.
The precharacterized signal data stored in cell entry 300 can be then used during timing analyses to derive a model driver output signal based on the model output capacitance (and signal type). For example, FIG. 3C shows a graph of rising driver output signals V_OUT(t)-11, V_OUT(t)-12, V_OUT(t)-13, and V_OUT(t)-14 (generated according to the precharacterization output delay and output slew values indexed by output capacitances C1, C2, C3, and C4, respectively, and input slew SI1 in cell entry 300 in FIG. 3B). To perform a timing analysis on a model driver cell, a model output capacitance value C5 is determined for that driver cell (based on the characteristics of the cell). For exemplary purposes, model output capacitance value C5 is selected to be between precharacterization output capacitance values C2 and C3. A model driver output signal V_OUT(t)-INT(C5) can then be interpolated from the precharacterized driver output signals V_OUT(t)-12 and V_OUT(t)-13 (associated with output capacitance values C2 and C3, respectively). Output slew and delay values for the model driver cell can then be derived from model driver output signal V_OUT(t)-INT(C5). Alternatively, output slew and delay values for the model driver cell can be directly interpolated from the precharacterization output delay and slew values of cell entry 300 in FIG. 3B.
As the devices used to instantiate the driver cells in a system continue to shrink, the driver cells formed from those devices begin to exhibit increasingly complex output current responses that are not adequately described by output slew and delay values. For example, reduced device dimensions generally result in faster circuits, which in turn requires greater modeling accuracy. To provide this enhanced modeling accuracy, the nuances of device behavior (in particular output current behavior) must be properly captured. Therefore, modern EDA tools have begun to incorporate output current-based schema (rather than output delay/slew-based schema) for cell modeling.
For example, FIG. 4 shows a driver model 210B for modeling driver cell 210 shown in FIG. 2. Driver model 210B includes a time-dependent voltage source V210B in series with a drive resistor R210B and driver output pin 212B, and an output capacitor C210B coupled between pin 212B and ground (Thevenin model). Driver model 210B is therefore substantially similar to driver model 210A shown in FIG. 3A, except that model 210B is precharacterized by measuring output current signals I_OUTB(t) across a range of input slews SI and output capacitance values C1 through CN. The output current signals I_OUT(t) can then be compiled in a precharacterized library cell entry for driver cell 210. An example of this output current-based approach is described in co-owned, co-pending U.S. patent application Ser. No. 11/866,981.
However, while an output current-based approach can provide greater modeling accuracy for small device effects, indexing output current according to output capacitance requires that the output capacitor be fully charged or fully discharged at the start of the output current signal (i.e., the output capacitor must initially be at a known state at one of the power rails). Unfortunately, this assumption cannot be made in a systems that includes multiple driver cells operating at different times (i.e., “multi-driver” systems).
For example, FIG. 5A shows a system 500 that includes an aggressor driver cell A510 and a victim driver cell V510. Aggressor driver cell A510 is modeled as a resistor R_AGG and an output capacitor C_AGG, and is configured to generate an output signal S_OUTDA from an input signal S_INDA. Victim driver cell V510 is modeled as a resistor R_VIC and an output capacitor C_VIC, and is configured to generate an output signal S_OUTDV from an input signal S_INDV. The outputs of aggressor driver cell A510 and victim driver cell V510 are parasitically coupled, as indicated by capacitor C_PAR.
Because of this parasitic coupling, crosstalk can exist between aggressor driver cell A510 and victim driver cell V510. For example, if aggressor driver cell A510 is switching in the same direction as victim driver cell V510, output signal S_OUTDV from victim driver cell V510 could exhibit a slew much greater than the typical best case (i.e., no load) slew value. On the other hand, if aggressor driver cell A510 is switching in the opposite direction from victim driver cell V510, output signal S_OUTDV from victim driver cell V510 can exhibit a significantly decreased slew.
Furthermore, if aggressor driver cell A510 begins switching before victim driver cell V510, the output of victim driver cell V510 can actually be pulled outside of the circuit power rails. For example, FIG. 5B shows a sample graph of output signal S_OUTDV generated by victim driver cell V510 for the situation when aggressor driver cell A510 starts a falling transition before victim driver cell V510 begins switching. Victim output signal S_OUTDV is initially pulled below ground (0.0 V) before beginning its upward trajectory. Because conventional output current-based driver models require that initial capacitance states be well-defined (i.e., voltage at one of the power rails), such models are not well-equipped to deal with multi-driver systems (i.e., systems that are faced with crosstalk among driver cells).
Thus, conventional cell driver models can be inadequate for the timing analysis of modern IC designs. Accordingly, it is desirable to provide a cell driver model that can accurately represent the behavior of a driver cell in a multi-driver system.